September 9, 1997 


Notes from JAD #1 
Product Testing Laboratories 


Philip Morris USA Confidential 


Receiving & Smoking Lab 

• Real time update of backend: Some functions such as updating CQS report distribution lists do 
not take effect until next day. The update runs at night, so have to wait until next day to print and 
distribute reports. Can it be changed to take effect immediately? 

• Manufacturing Specs Program: Need better way to deal with list of production brands requiring 
daily testing, and to remove brands not tested daily. QSS designates which brands are to be tested 
daily, and the list may change several times per quarter. Current default for all brands set to YES. 
Change default to NO, change current daily brands (60) to YES, and provide lookup table to handle 
quarterly adjustments. Check with R. Llpps. 

• Add values during receiving: At time of receiving, have option to add butt and tipping length 
values at same time analyst is selecting tests for the request. Also keep the current option of editin g 
in butt and tipping values. 

• Deleting a Request: Provide option for canceling / deleting a request with no data, without having 
to ‘fake out’ the system. If not deleted, request continues to appear on reports. LIMS can handle 
this by posting to system as canceled by the audit function. 

• Delete test data by sample: Need the option to delete test data by sample if appended incorrectly. 
Currently, the only option is to delete one test at a time. Would like the ability to delete any one or 
all tests. LIMS can handle; will be audit trailed. 

• Display data from multiple databases on same report: Need ability to pull historical data 
(averages) from databases (Cl, production audit) and display on CQS reports for comparison with 
test data. Brand coding systems are different for each database. Issue for further discussion. 

• Replicate sample codes: For this particular item, we currently have a batch option, but you have 
the ability to only add numerical codes. I believe what Martha was referring to is the ability to 
“batch” sample codes and then have another option to “add” a suffix or prefix to differentiate one 
sample code from the other. This is needed when smoking monitors for instrument validation. 

This is done twice each week for each smoking machine. Will also be needed for non-smoking 
instrument validation. 

Examp le - MON9716 would be the sample code which needs replication. The option would be to 
add a (Prefix) A-MON9716 or (Suffix) MON9716-A. 

• Next available request code: Current method consists of a log book (paper) from which next 
available request code is issued. Let LIMS provide next available request code. 

• Request code length: Currently limited to 10 characters for request code. Need to increase. 

• Due date: Currently have a ‘due to customer’ date. Also need a ‘lab completion’ date. 

• Modify GCC and Production Audit Reports: When a spec change has been made for a reported 
test (tar, Nic, vent, total RTD, plug RTD, perm, tobacco weight, etc.) a flag should be inserted so 
that ‘old’ (prior to spec change) data does not average in with new data, 
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• Exceptions to normal test procedure: An example would be limited sample quantity. Audit trail 
must show why 10 cigarettes were tested instead of the standard 25. This could be included as part 
of the sample description. 

• How long do we save data? 

* Raw data or averages 

• Regulatory requirement 

• PM requirement 

* Calibration data is saved with sample analysis data 

• Borgwaldt Smoking: When Borgwaldt doesn’t smoke all the ports, there is currently no method 
for entering a reason why. R. Buckner will discuss this with R. Greene. 

• Puff by Puff analysis: Currently done manually on Filtrona RM20 smoking machine. Can it be 
interfaced and reported by LIMS. Need to designate a standard balance and interface balance only. 
J. Garmon will provide details. 

• Smoking Lab conditions: Capture all physical conditions (temp, RH, etc.) on LIMS. This is 
required in all conditioned areas. J. Garman & K. Hughes will provide details. 

• Smoking Lab operations: Have LIMS track some operations that are currently tracked on paper. 

J. Garman & K. Hughes will provide a list. R. Greene is writing software that will include 
calibration. 

• Security measures: password (FDA has approved electronic signatures), company badge, 
watchman (credit card reader), fingerprint reader, retinal scanner. 

• Work Requests (yellow & blue sheets): All information is currently entered by the Receiving 
analysts. Let customer provide (enter) as much of this as possible from his computer. Include 
some fields that are required (forces customer to adequately identify samples). Provide link to 
semi-works system for that information to default to work request. 

Can sample descriptions be limited to 50 most common for pull down menu? Description field 
could be divided into multiple fields (expected tar, menthol / non-menthol, etc.). What are the legal 
issues? Issue for further investigation. 

• Validation of Reports: Whenever a new test or instrument is added to the system, must validate 
the report. Unapproved data & preliminary reports violate regulation. Can’t ship product on 
preliminary data. Transferring data to Excel for analysis of historical trends does not require 
validation of report. 

• How indexible is LIMS to changes after the fact? Easy to add new test, new field, make work 
list changes. Difficult to change or add triggers. 

• Smoking Group numbers: It is acceptable (for regulation) to reuse group numbers as long as 
request codes are unique. Need a better method of tracking by sample identification and smoking 
group number. 

• LIMS Sample number: A consecutive number that is absolutely unique to the system and 
accompanies each unique sample. 
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Nicotine & Water Lab 

Water calculation (based on blanks) is currently done at pc level (Windows program). Results 
approved and then sent to database. Nicotine results are sent from chemstation to database with no 
intermediate calculation required for nicotine. Calculations are also dependent on which smoking 
machine was used. Need to carry through smoking machine ID, which is not currently done. When 
data are shipped from chemstation to database, the analyst is tracked. 

• Standards; When new standard solutions are made, send information to LIMS. What data could 
go in for verification process on LIMS? J. German will provide details. 

• Scan samples received from smoking lab; Currently written into log book. Would need method 
for identifying analyst (currently have one group lab password). Don’t want to waste time logging 
on and off as analysts change. 

• What kinds of traceability and accountability are required? Replace paperwork with electronic 
functions: (1) who logged in samples (2) who loaded samples on GC (3) scan samples into LIMS 
and transfer samples to chemstation (4) trace which Gilson dispensing unit is used to fill and vial. 
There are currently two new Gilsons (Model 215) that are interfaced to instruments but not to 
database. 

• Nice to Have: Twenty vials are loaded on the GC for each smoking run. This currently requires 
scanning 20 tubes. Could it be set up to scan once for a complete run. If dividing the run between 
two GC’s, would require scanning each tube. 

• GC monitor, calibration, control charting: Can LIMS do SPC rather than using current method, 
which is to query the database with Brio and put results in Statistica to create control charts? GC 
monitor is a pre-made solution run to verify the GC. Can LIMS reference historic data from 
individual GC’s and flag runs that do not meet smoke monitor (IM#16) limits? 

• Error shipping to database; If a port of Nic/Water (or any test value) does not ship from 
instrument to the database, due to a barcode error or other reason, is there a way to let the lab 
know? There is currently no feedback from database if a result does not ship. This is being taken 
care of in the new software written by R. Buckner, which communicates directly with database 
(Chemstation, filter length, oven volatiles). All software should be converted in about a year. 

Menthol Lab 

• Automate factors for various tests: (1) Extraction solution (2) Sample weight (3) Calculation 
factors. This can be predefined in LIMS for each test. Will need ability to edit this information in 
case of limited sample quantity, etc. Currently putting factor into Chemstation for calculations. 

Wet Chemistry Lab 

• Standard regression: Currently get printout on strip chart. Store locally or on LIMS? How long? 

• Alkaloid & sugars analysis: We have newest release of AlpChem software, but not yet installed. 

• Sample Grinding: Can LIMS track who grinds filler samples and date ground? Would be helpful 
to know when samples are ground and ready to be tested. 
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Gas Phase Lab 

• FTIR scans: Not currently retained. The data (CO) are retained. 

• Ventilation screening: Prior to gas phase analysis, cigarettes are ventilation screened to +/- target. 
There is a question whether we should continue doing this. Issue for later. 


Physical Testing Lab 

• Retest feature: Provide function at instrument operator level to immediately edit and retest one of 
the test replicates in the event of an error (such as hole in cigarette discovered after tested). This 
would be audit trailed with a pick list of standard reasons for retesting. 

• Recheck log: PT Lab currently has a hand-written recheck log. For all rechecks, they record 
request code, sample code, date requested, requester name, reason, initial value, instrument ID, and 
recheck value. Can the LIMS track this? Would also need function for analyzing rechecks for 
trends (this often helps identify instrument or operator problems). A Recheck Count Report was 
suggested. It would be run each morning for previous day’s work showing test, instrument ID, 
operator, reason for recheck, etc.. Use of recheck logs may also apply in other PTL labs. 

• Historical data: We have historical databases for Production Audit and Domestic Cl. It would be 
helpful for operator to see historical value at the time of testing, as most rechecks could be taken 
care of immediately. Marty suggested a split screen showing graph of last 6 months historical data 
(average and SD) with current value highlighted. 

• Cancel rechecks when no retain sample available: Have LIMS auto-cancel request for recheck 
when no retain sample is available. Would require logging in number of retain packs for every 
sample. A daily report was requested providing list of all rechecks that were auto-canceled. This 
may not be feasible because of the time required to log retain information for every sample, 
and because of the limited space available for holding retains. 


Microscopy Lab 

• Approving a Request: Provide a more flexible format for reviewing and approving microscopy 
lab data. Currently data is viewed and approved using an edit by test option in the CQS. Each 
individual test must be called up (one at a time), reviewed and approved before moving on to the 
next test. The desired format would be to call for multiple tests (sets of tests) and to review and 
approve in sets. The three logical test sets would be (1) blend data (2) non-blend data (3) carbon 
(the carbon in plug test would not be viewed with any other test). Examples are attached for the 
three data approval screens. 

• Denier per filament: Transfer of denier per filament data from visual basic program to database is 
currently done by manual entry. R. Buckner will prepare program to eliminate manual entry. 
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Process Monitoring Lab 

• General information (current status): Customers require fast turnaround (Primary, Process 
Engineering...). PML has its own receiving function. PML requests are logged into system by 
customer. Customer delivers test samples and a copy of their request to verify receipt by PML. 
PML generates its own barcodes. Electronic data (average result) are saved on database for 
indefinite period. Raw data retained on paper for one year in the lab. 

• Operator ID: Need method of tracking user / operator identification within PML. Current audit 
trail is limited ; no way to identify who generated barcodes, why or who deleted barcodes from the 
system, etc. 

• Work lists: Editing a mistake in a work list is difficult and time consuming. This is an old DOS 
program that has not been updated to Windows. 

• Weight Selection: The weight selector is not interfaced; however, a project request has been 
submitted to FTD. 

• Data approval / availability: There is a 30 to 45 minute delay between approval of data and 
availability for customer. This will go to real time when the new balances are interface. 

• Label Printers: Label printers were suggested for PML, since proper labeling will be a 
requirement of regulation. Currently, customers deliver samples in bags with handwritten labels 
(often difficult to read, marked out and corrected). 

• Future Requirement: Semi-works system must talk to LIMS (largest producer of samples). This 
would also be a benefit to the other labs in PTL. 

• PML Wish List 

* Several options should be available for data approval within one approval function: (1) 
Approve individual values (2) Approve samples (3) Approve a request. 

* Operator password tracking 

* Operators should not be able to delete requests. When requests must be canceled, there should 
be an audit trail. 

* Provide for interchange between work stations (hold data locally until process is completed). 
For a 2-step process, be able to run work list and weigh up on one work station; weigh back and 
complete request on another work station. Physical Testing Lab could also benefit from this 
capability. 

* If network is down, be able to continue testing and store data locally. 

* Be able to assign a request to a specific operator, and have same operator follow through to 
completion. 
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